Bejegyzés dátuma: 2022. 03. 22
Ahogy a legtöbb fejlesztőmérnök, úgy mi is kognitív tanulási rendszerben szocializálódtunk. Az információt így szaktanároktól és tematikus szakkönyvekből szereztük meg és dolgoztuk fel. Gyakorló mérnökként a hibákból, következményekből és a teljesítményekből gyűjtött tapasztalati tanulást részesítjük előnyben, ami a fizikai környezet által és az információ szakszerű feldolgozásával szélesebb körű megértést tesz számunkra lehetővé.
Jelen írásomban személyes tapasztalataimat szeretném megosztani azokkal a kollégákkal, akiket érdekel egy modulárisan bővíthető távfelügyeleti platform, a MonitoringBook 2.0 kifejlesztésével járó felhasználói elvárások és üzemeltetési igények kihívásainak kezelése, valamint azok támogatása.
A történet kicsivel több, mint 15 éve kezdődött, amikor távfelügyeleti GSM kommunikátorok fejlesztésébe kezdtünk az egyetemi csoporttársammal, Mozgó Zsolttal. Ekkor még egyáltalán nem rendelkeztünk semmilyen grafikus távfelügyeleti szoftverrel, ami képes lett volna megjeleníteni az általunk gyártott berendezések jelzéseit. Ennek támogatása érdekében fejlesztettünk egy IP alapú vevőállomás szervert, amit soros porton csatlakoztattunk egy kliens számítógéphez, amin akkor a Mimas, majd az Alarmsys futott. Ezek a „vastagkliens” távfelügyeleti szoftverek számos értékes funkcióval rendelkeztek, viszont üzemeltetési oldalról nem voltak felkészítve több millió eseményüzenet valós idejű fogadására, valamint több száz felhasználó párhuzamos csatlakozására és egyidejű kiszolgálására.
Ezek a „vastagkliens” programok még olyan kommunikációs technológiák támogatásához (kapcsolt telefonvonal, UHF rádió) lettek kifejlesztve, ahol a napi jelzésszám nem érte el a készülékenkénti tíz eseményjelzést. Az IP alapú távfelügyeleti vevőállomás szerverek viszont több százezer jelzést képesek másodpercenként fogadni, így nem mindegy, hogy milyen jelzésszámra és kiszolgáló alkalmazásokra van felkészítve egy távfelügyeleti állomás szoftvere.
„A vastagkliens név (informatikus tolvajnyelv) amúgy onnan jön, hogy a hálózatok megjelenésével a korábbi elszigetelt számítógépeken futtatott izolált alkalmazások helyett elkezdték kihasználni a hálózat nyújtotta előnyöket, így az adatokat egy központi gépen tárolták egy adatbázisszerveren, és a számítógépeken továbbra is önállóan futó, csak az adatért a szerverhez forduló programok futottak. Ez volt a kliens-szerver architektúra, más néven kétrétegű architektúra. Egy réteg vastag, ha nagyon sok és bonyolult műveletet hajt végre. A számítógépre telepített szoftver pedig a műveletek nagy részét végzi, így vastagkliens lett a neve.” (Forrás: studicore.hu)
Az internet alapú (IP) átjelzési technológia nagyobb számítási kapacitást, komplexebb üzemeltetési struktúrát és szerteágazó informatikai képességeket igényelt a távfelügyeleti állomások üzemeltetőitől. Ezt felismerve azonnal belekezdtünk egy olyan modern infrastruktúra fejlesztésébe, ami hosszútávon képes az üzemeltetési igényeket stabilan és biztonságosan kiszolgálni. Így született meg a Java nyelven íródott első távfelügyeleti vastagkliens szoftverünk, a Mercurio Commander.
Az IP technológiában rejlő üzleti és üzemeltetési lehetőség számos távfelügyeleti szolgáltató fantáziáját mozgatta meg, amit tömeges technológiai transzfer követett. Az átállás okán egyre több szolgáltató cserélte le régi rendszerét az általunk fejlesztett megoldásra. A távfelügyeleti szerverek számának jelentős növekedése és a hozzájuk kapcsolódó egyedi ügyféligények kiszolgálása viszont egyre nagyobb kihívások elé állított bennünket.
A vastagkliens szoftver kezdetben jó ötletnek tűnt, mert Java alapokon, hosszútávon skálázhatónak találtuk. A Java viszont speciális környezetet igényelt a távfelügyeleti szoftver futtatásához, aminek rendszeres frissítése az állomás üzemeltetőinek folyamatos feladatot adott. Ezzel azonban senki sem szeretett foglalkozni. Frissítésre ugyanakkor nem csak a futtató környezetben volt szükség, hanem az IP alapú vevőegységek szervereinél és azok vastagkliens szoftverénél is. Ilyenkor egyenként kellett frissíteni az élesben működő szervereket (elsődleges + meleg tartalék): a régi adatbázis migrálása az új rendszerbe, Java futtató környezet frissítése, a grafikus megjelenítő szoftver új verziójának telepítése. A kockázat minimalizálása érdekében naponta csak egy távfelügyeleti szolgáltató állomását frissítettük. Ez a fajta rendszertámogatás egyrészt roppant sok időt és erőforrást igényelt, másrészt lassította az újabb verziók kiadását is, amivel gyorsabban fejlődhetett egy távfelügyeleti szolgáltató rendszere. Miután felismertük, hogy ez a fajta üzemeltetés akadályozza a MOHAnet küldetését, döntést hoztunk egy új távfelügyeleti infrastruktúra létrehozásáról.
A vállalkozás indulásakor azt tűztük ki küldetésünknek, hogy megváltoztatjuk a világban azt, ahogy az emberek a távfelügyeleti szolgáltatásokról gondolkodnak valamint azt, ahogy igénybe veszik őket. Minden döntésünket a mai napig ez az elv vezérli.
Az új infrastruktúra egy felhőszolgáltatásra épülő „vékonykliens” technológia lett. Ez a megközelítés számos ismert üzemeltetési és fejlődési nehézséget orvosolt azok közül, melyektől korábban partnereink és mi magunk is szenvedtünk. Az új megoldásnak köszönhetően a távfelügyeleti szoftvert a felhasználó bármilyen számítógépen tudja használni egy webböngésző segítségével, amit egy Javascriptben megírt program támogat. Az előfeldolgozott adatokat egy felhőszervertől kéri el, így a kliensnek mindössze annyi dolga van, hogy megjeleníti azokat. Ezért is nevezi a szakma a webböngészőben futó grafikus szoftvereket vékonykliensnek. Talán egyszerűnek hangzik, de a valóságban számos szakmai kihívással és kompromisszummal járt ez a fejlesztés, viszont rugalmasan skálázható erőforrást és stabilabb üzemeltetést ígért a gyors növekedéshez.
A felhőszolgáltatás akkor még új technológiának számított a piacon, így menet közben még azt is meg kellett tanulnunk. Ezt követően újraírtuk az IP alapú vevőállomás szerver szoftverét (backend) és a hozzá kapcsolódó grafikus megjelenítő felületet (frontend), amit már platformként definiáltunk, mivel magába foglalta az egymástól teljesen függetlenül üzemelő távfelügyeleti szoftvereinket (Observer, Datamatic) is. A konszolidáció következtében a termékeink támogatása is lényegesen leegyszerűsödött.
Célként ugyanis egy olyan modulárisan bővíthető távfelügyeleti platform megvalósítását tűztük ki, ami számos alkalmazást képes egy rendszerből kiszolgálni. Több, mint három éve sikerült is mindent megvalósítanunk, amit vizionáltunk. Az ügyfeleink egy része viszont nem volt elragadtatva az új platform kezelésétől, így a korábbi szoftvereink használata mellett maradtak. Számos funkcionális ügyféligényt kiszolgáltunk és üzemeltetési problémát megoldottunk az új platformmal, csak sajnos arra nem figyeltünk kellőképp, hogy az új megjelenítő felületnek jobb felhasználói élményt kell nyújtania, mint amit a korábbi programjainknál már megszoktak az ügyfeleink. Követtünk minden technológiai trendet mégsem segített a felhasználói élmény javításában. A MonitoringBook 1.0 sokkal többet tudott, mit bármelyik más programunk korábban, de a felhasználó élmény az ügyfeleink visszajelzései alapján sajnos rosszabbra sikerült.
A korábbi szoftvereinkben az egyes nyilvántartók és kimutatások a főképernyő felső sávjában helyezkedtek el toolbar ikonként, így azok bármikor elérhetők voltak a felhasználók számára. Az új változatban viszont a trendek követése okán már minimál dizájnt alkalmaztunk a grafikus felülethez, ahol a letisztultság megtartása érdekében már nincs értelmezve a felső menüsor. Az új menürendszer, a mobiltelefonoknál alkalmazott hamburger gomb (a képernyő bal sarkában található három vízszintes vonal egymás alatt) megnyomásával volt előhívható egy oldalról beúszó „drawer” (fiók) elrendezésben. A fiók ugyanis mindent elnyel, de sokkal többször kell nyitogatni, és ha valami benne lejjebb található, akkor még görgetni is szükséges a felhasználónak. Rossz volt újra megélni, hogy amit hosszú éveken keresztül nagy odaadással terveztünk és fejlesztettünk mégsem aratott osztatlan sikert az ügyfeleink körében.
Akik szoftverekkel dolgoznak naponta, azoknak a munkájukat egyszerűsíteni kell, nem pedig bonyolítani. Ennek okán úgy döntöttünk, hogy lecseréljük a több év alatt megírt új frontend felületünket egy olyan változatra, ami már a partnereink elképzeléseihez illeszkedik. A tavalyelőtti év (járvány kezdete) elejét ezért arra szántuk, hogy újragondoljuk ismét a MonitoringBook grafikai megjelenítését, és egy sokkal egyszerűbben kezelhető távfelügyeleti platformot alkossunk belőle a meglévő felületek teljes átalakításával. Kiváló fejlesztőink vannak, de a szoftverfelhasználói élmények javítása és növelése külön képességet és szakértőt igényel, ezért megbíztunk egy profi UI/UX tervezőt (user interface/user experience), aki beült az Országos Távfelügyelet diszpécsereihez és figyelte a munkájukat. Az egyes beavatkozásoknál mindig kérdezett, és a kérdés szinte mindig ugyanaz volt: „Mit csinálnál másképp, hogy ezt a feladatot egyszerűbben és kényelmesebben elvégezhesd?” Nem gondoltuk, de a diszpécserekből dőlt a szó. Ezt követően személyesen felkerestem néhány partnerünket a korábban adott értékes visszajelzésükért cserébe és biztosítottam őket, hogy a grafikus felület újraírása a jelzett igényeik alapján megkezdődött. Szerencsére tőlük is rengeteg ötletet kaptunk, amiből sikerült megtervezni a MonitoringBook 2.0 grafikus felhasználói felületét.
Az új MonitoringBook 2.0 moduláris felépítésének köszönhetően könnyen és rugalmasan bővíthető új funkciókkal és értéknövelt szolgáltatásokkal. Belépéskor eldönthetjük, hogy melyik távfelügyeleti alkalmazás modulját (riasztófelügyelet, járműkövetés, járőrellenőrzés, fogyáskövetés, fertőtlenítés, stb.) szeretnék használni. Az adott modulba belépve pedig csak olyan funkciókkal és szolgáltatásokkal találkozhatunk, amik kizárólag a választott alkalmazás moduljához kapcsolódnak, mint ahogy ezt a legelső távfelügyeleti szoftvereinknél ügyfeleink már megszokhatták. A fejlécben visszahoztuk az egyes parancsikonok (toolbar) megjelenítését, melyek modulonként különböznek egymástól. Az egyes modulok közti váltás természetesen menet közben is könnyen megoldható. A modulrendszerű felépítésnek köszönhetően megszűnt a zsúfoltság és a nem releváns funkciók megjelenítése, amit korábban a fiók rendszer okozott. A jövőt nézve pedig egy új alkalmazásmodul kifejlesztése már nem években, hanem csak néhány hónapban mérhető, legyen szó beltéri helymeghatározásról vagy videó távfelügyeletről, mivel ez az infrastruktúra már rendkívül egyszerűen és gyorsan skálázható. Az új MonitoringBook 2.0 platform kiadása modulonként történik Az első modul kiadása a SecuriForum kiállítással egyidőben lesz elérhető minden meglévő és leendő partnerünk számára.
Érdekli, hogyan növelhetjük biztonságát, versenyképességét egyedi fejlesztéseinkkel?
Adja meg elérhetőségeit és munkatársunk rövid időn belül felveszi Önnel a kapcsolatot, hogy személyes találkozót egyeztessünk, ahol felmérjük az igényeit - és egyedi megoldást kínálunk.